Arquitectura de una Red IMS
La red IMS es una red IP multi-servicio, ofrece todo tipo de servicios orquestados por una red ‘’nuclear’’ soportando diferentes niveles de calidad de servicio que podrán ser ofrecidos al usuario. También es considerada una red multi-acceso ya que toda red de acceso “banda ancha”, fija y móvil, puede acceder a ella. El IMS no es una única red sino diferentes redes que ínter-operan gracias a distintos acuerdos de roaming IMS fijo-fijo, fijo-móvil, móvil-móvil. El IMS es un “enabler” o catalizador que hace posible a los proveedores de servicios ofrecer: *Servicios de comunicaciones no tiempo real, seudo tiempo real y tiempo real según una configuración cliente-servidor o entre entidades pares. *La movilidad de servicios / movilidad del usuario (nomadismo). *Varias sesiones y servicios simultáneamente sobre la misma conexión de red. Capas de Red En la imagen se puede contemplar un mapa conceptual de una red IMS. Como se puede apreciar, la estructura de los nodos está estratificada según las capas de servicio. La arquitectura de una red IMS engloba 3 capas, si bien profundizaremos sólo en dos de ellas (capa de Control y capa de Aplicación), cabe mencionar una breve descripción, algo más técnica que las comentadas anteriormente, sobre cada una de ellas: *La capa de TRANSPORTE representa una red IP. Esta red IP podrá integrar mecanismos de calidad de servicios con MPLS, Diffserv, RSVP, etc... La capa de transporte está compuesta de enrutadores o routers conectados por una red de transmisión. Distintas pilas de transmisión pueden ser contempladas para la red IP: IP/ATM/SDH, IP/Ethernet, IP/SDH, etc… *La capa CONTROL está formada por controladores de sesión responsables del encaminamiento de la señalización entre usuarios y de la invocación de los servicios. Estos nodos se llaman “Call Session Control Function” o CSCF. Es aquí donde IMS introduce un ámbito de control de sesiones sobre el campo de paquetes. *La capa APLICACIÓN introduce las aplicaciones (Servicios de Valor Añadido) propuestas a los usuarios. El operador puede posicionarse gracias a su capa CONTROL como integrador de servicios ofrecidos por el mismo o bien por terceros. Esta capa la componen servidores de aplicación “Aplication Server” o “AS” y “Multimedia Resource Function” o “MRF” que los proveedores llaman Servidores de Media IP (“IP Media Sever” o “IP MS”). Los nodos que hemos citado como Call State Control Function, son considerados el centro neurálgico de la red IMS. Estos nodos controlan todo el tráfico de sesiones existentes en la red. Este nodo, en realidad está formado por otros tres más pequeños cuyas funciones quedan bien definidas: *''Proxy Call State Control Function (P-CSCF). Es el primer punto de contacto para los usuarios de la red IMS. Esto significa que todo el tráfico de señalización SIP desde el UE será enviado al P-CSCF. Asimismo, todos los mensajes SIP de terminación de la red de señalización se envía desde el P-CSCF para el UE. El P-CSCF se asigna al terminal IMS durante el registro IMS y no cambia durante dicho proceso. *''Interrogating Call Session Control Function (I-CSCF). ''Es un punto de contacto dentro de la red del operador para todas las conexiones destinadas a un abonado de ese operador de red. El I-CSCF es un proxy SIP situado en el borde de un dominio administrativo. La dirección del I-CSCF está contenida en el DNS (''Domain Name System). *''Serving Call Session Function Control (S-CSCF).'' Es el punto focal de la IMS, ya que es responsable del manejo de los procesos de registro, tomar decisiones de enrutamiento, ese encarga del mantenimiento de los estados de sesión y de almacenar el perfil de servicios de cada usuario. Cuando un usuario envía una solicitud de registro, éste se dirige al S-CSCF, que descarga los datos de autenticación del HSS. Basado en los datos de autenticación se genera un ‘Request for Credentials’ al UE. Después de recibir la respuesta y la verificación, el S-CSCF acepta el registro y comienza a supervisar el estado de registro. Después de este procedimiento, el usuario es capaz de iniciar y recibir servicios de IMS. Por otra parte, el S-CSCF descarga un perfil de servicio del HSS como parte del proceso de registro y entrega la información de usuario y dispositivo específico del UE registrado. En la figura vemos un diagrama explicativo del proceso de registro de un usuario en la red IMS. En el diagrama se hace mención a otro nodo, que si bien en el primer diagrama se ha colocado en la capa de servicio, estaría englobado en la capa de control. Se trata del Home Subscriber Server (HSS). Este nodo es una base de datos que sirve como repositorio central de información relacionada con el usuario. Técnicamente, el HSS es una evolución del HLR (Home' Location Register)'', de la red GSM. El HSS contiene todos los datos relacionados con el usuario y requiere suscripción para manejar sesiones multimedia. Estos datos incluyen, entre otros, información de ubicación, información de seguridad (incluyendo la autenticación y la información de autorización), la información de perfil de usuario (incluyendo los servicios a los que el usuario está suscrito), y el S-CSCF asignado al usuario. Dentro de la capa de Aplicación se hace mención a los siguientes nodos: *Media Resource Function (MRF) el cual proporciona una fuente de medios de comunicación en la red doméstica. Posee la capacidad de reproducir anuncios, mezcla de flujos de medios (por ejemplo, en un puente de conferencia centralizada), transcodificación entre diferentes codecs, obtener estadísticas, y hacer cualquier tipo de análisis de medios. *Application Server (AS). Es una entidad SIP que aloja y ejecuta servicios (servicio VPN, servicios básicos, servicios avanzados, etc...). El AS será tratado con mayor detalle en futuros posts. En el plano de la señalización, un nodo que merece especial mención es el Media Gateway Control Function (MGCF) que realiza conversiones de protocolo entre SIP y la parte de usuario (ISUP). En el plano de media, el MGCF es capaz de enviar y recibir datos de comunicación IMS sobre el Protocolo RTP en un lado, mientras que en el otro utiliza uno o más PCM (Pulse Code Modulation) para conectarse a la red de CS. Además, la MGW realiza la transcodificación cuando el terminal IMS no es compatible con el códec utilizado por el lado de CS. Session Initiation Protocol (SIP) SIP es un protocolo desarrollado por el grupo del IETF con la intención de ser el estándar para la iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos multimedia como el video, voz, mensajería instantánea, juegos en línea y realidad virtual. La sintaxis de sus operaciones se asemeja a las de HTTP y SMTP, los protocolos utilizados en los servicios de páginas Web y de distribución de e-mails respectivamente. Esta similitud es natural ya que SIP fue diseñado para que la telefonía se vuelva un servicio más en Internet. En noviembre del año 2000, SIP fue aceptado como el protocolo de señalización de 3GPP y elemento permanente de la arquitectura IMS. SIP es uno de los protocolos de señalización para voz sobre IP, otro es H.323 e IAX2. En este trabajo no se pretende dar una información excesivamente extensa y detallada sobre el protocolo SIP, por lo que sólo destacaremos aquellos conceptos que sean de relevancia para nuestros intereses. SIP es un protocolo de solicitud / respuesta. Un cliente es una entidad SIP que genera peticiones. Un servidor SIP es una entidad que recibe las solicitudes y devuelve respuestas. Nos referimos a diálogo o transacción SIP al conjunto de petición más conjunto de respuestas que genera dicha petición. Cada respuesta tiene un código que indica el estado de la transacción. Cada petición SIP contiene un campo, llamado a un método, que denota su propósito. La siguiente tabla muestra los principales métodos utilizados. En la siguiente tabla se muestran las diferentes clases de respuestas SIP: Un diálogo básico de SIP se establece a través de la llamada de tres vías (INVITE - 200 OK - ACK). INVITE es el único método que utiliza un protocolo de tres vías en lugar de un protocolo de enlace de dos vías (MÉTODO de final de la respuesta). Tanto las solicitudes como las respuestas pueden contener organismos SIP. El cuerpo de un mensaje es su carga útil. Estos cuerpos suelen consistir en una descripción de la sesión. Llamada SIP Básica La siguiente figura muestra una conversación de audio entre dos UA, Laura y Bob, que se ha establecido correctamente y posteriormente liberada: El cuerpo de las solicitudes INVITE contiene la descripción de la sesión. Por ejemplo, cuando Bob llama a Laura, su UA envía un INVITE con una descripción de la sesión para el UA de Laura. Supongamos que el UA Bob utiliza SDP para describir la sesión. Su UA recibe la invitación con la descripción de la sesión siguiente: ''v=0 o=Bob 2890844526 2890842807 IN IP4 131.160.1.112 s=I want to know how you are doing c=IN IP4 131.160.1.112 t=0 0 m=audio 49170 RTP/AVP 0'' El INVITE recibido por Laura significa que Bob está invitando a Laura a unirse a una sesión de audio. A partir de la descripción de la sesión realizada en el INVITE, Laura sabe que Bob quiere recibir los paquetes de voz usando el protocolo Real-time Transport Protocol (RTP) en 131.160.1.112:49170 User Datagram Protocol (UDP). Su UA también sabe que Bob puede recibir voz codificada mediante Pulse Code Modulation (PCM). (RTP/AVP 0 en la línea ’m’ lo indica). En este caso particular, sólo se ofrece un codec, pero normalmente suelen ofrecerse un mayor número de codecs soportados para la sesión de audio. El UA de Laura comienza alertando a Laura y devuelve un "180 Ringing" como respuesta al UA de Bob. Hay que tener en cuenta que existen otras respuestas provisionales que pueden ser enviados desde Laura a Bob antes como por ejemplo, "183 Session Progress" en caso de que Early Media se hubiera establecido (caso mostrado en la figura anterior). Cuando Laura finalmente acepta la llamada, su UA devolverá un "200 OK" con una descripción de la sesión en el mismo: ''v=0 o=Laura 2891234526 2812342807 IN IP4 138.85.27.10 s=I want to know how you are doing c=IN IP4 138.85.27.10 t=0 0 m=audio 20000 RTP/AVP 0'' En este punto, Laura acepta la llamada e informa a Bob de que recibirá los paquetes RTP en el puerto UDP 138.85.27.10:20000 (ver arriba). El códec que se ofrece es aceptado. Este modelo de negociación SDP es el modelo denominado solicitud/respuesta que comentábamos anteriormente. Si, cuando Laura y Bob están en medio de la sesión, uno de ellos desea modificar el período de sesiones, sólo tienen que emitir un nuevo INVITE. Este tipo de INVITE, llamado re-INVITE, realiza una descripción de la sesión actualizada. Podría consistir en nuevos parámetros como el número de puerto para los medios de comunicación existentes, o bien puede agregar nuevos flujos de medios. Por ejemplo, Bob y Laura pueden agregar una secuencia de vídeo a la conversación de voz a través de un re-INVITE. Significativamente, SIP sólo se ocupa de la invitación para el usuario y la aceptación del usuario a dicha invitación. Todos los datos de sesión son manejados por el protocolo de descripción de sesión utilizado (SDP en este caso). Cabeceras SIP Existen multitud de cabeceras que utiliza el protocolo SIP, sin embargo, dentro de las cabeceras que nos podemos encontrar en un diálogo cualquiera (como en el visto entre Bob y Laura) existen cabeceras utilizadas en el protocolo SIP, otras que son específicas de la arquitectura IMS. En la tabla siguiente encontramos una descripción de algunas una de ellas: Negociación SDP (Session Description Protocol) En IMS se sigue un modelo de oferta/respuesta en términos de negociación SDP entre las partes implicadas: *El UE llamante envía una primera oferta SDP en la petición INVITE enviada al UE llamado. Este SDP muestra todos los tipos de medios (por ejemplo, audio, video, etc…) que la persona que llama desea utilizar para esta sesión y se enumeran los diferentes codecs que la persona que llama soporta para la codificación de los distintos tipos de medios. *El UE llamado responde con una primera respuesta SDP (dentro de una respuesta del tipo ‘183 Session in Progress’ por lo general, en la que se puede rechazar algunos de los tipos de medios propuestos. También selecciona para cada tipo de soporte un único codec, desestimando los que no quiere usar. En la siguiente figura vemos un ejemplo de mensaje SDP ofrecido por un llamante (que denominaremos número ‘A’) a un llamado (que denominaremos númoer ‘B’): Como se puede comprobar, la cabecera SDP contiene información relacionada con los códecs multimedia que se ofrecen: *El tipo de códec: audio, en este caso, aplicable a todos los codecs mencionados. *El protocolo utilizado a nivel de los medios de comunicación: RTP. También se indica qué puerto será utilizado por el UE que llama (el SBC en este caso) para enviar/recibir paquetes de medios. En este caso, que es el puerto 14532. También, en este caso, el UE que llama ofrece una serie de codecs de audio: 0 (G.711 μ-law), 8 (a-law), etc… Los campos de atributo de media proporcionan información adicional asociada a cada codec. También informa sobre el modo de conexión: si el canal de audio/vídeo es sendrecv (duplex), sendonly, recvonly. En la siguiente figura vemos la respuesta de ‘B’ a ‘A’. Nos fijaremos en el campo SDP del mensaje ‘183 Session in Progress’: El SDP establece qué códec ha sido elegido por ‘B’, en este caso el codec 8 (a-law). El modo sendrecv ha sido aceptado por ‘B’ que utilizará el puerto 25840 para enviar/recibir los paquetes de audio. Servidor de Aplicaciones La idea esencial de IMS es que sea considerada como una plataforma común para la prestación de servicios innovadores. El ejemplo expuesto en la figura1, en la que no intervenían servicios extra, era sólo un ejercicio práctico cuyo propósito es entender los fundamentos del enrutamiento y las peculiaridades entre el lenguaje SIP y el mundo IMS. Un ejemplo más realista incluye proporcionar uno o más servicios a la persona que llama, el destinatario de la llamada, o incluso ambos. Estos innovadores servicios se proporcionan a través del Servidor de Aplicaciones (AS). Desde el punto de vista de SIP, un AS puede actuar ya sea como un UA terminante como originante, a veces también puede actuar como un servidor proxy SIP, dependiendo del servicio prestado al usuario. Si el AS no proporciona servicio alguno, entonces actúa como un servidor proxy SIP. El AS que trataremos en los puntos sucesivos se comportará siempre como un B2BUA (Back-to Back User Agent). Un B2BUA son simplemente dos UAs conectados entre sí por una lógica específica de la aplicación. En general, un B2BUA realiza acciones similares a las de un servidor proxy SIP. Recibe pet iciones y las envía a otro lugar; recibe respuestas y las retransmite a la entidad de origen. Sin embargo, existen diferencias entre un proxy SIP y un B2BUA. Estas diferencias están relacionadas con el tipo de acciones que ambos pueden llevar a cabo y las consecuencias de la realización de esas acciones. Una petición ‘A’ se recibe en uno de los SIP UA, el cual hará llegar la petición a la lógica de la aplicación. La lógica específica de la aplicación se encarga de generar una respuesta ‘A’ y de crear una nueva petición ‘B’, que se relaciona en parte con la petición ‘A’. Estas peticiones están relacionadas sólo parcialmente ya que la lógica de aplicación puede cambiar cualquier cabecera, incluidas las de los campos que un servidor proxy SIP no puede modificar, como el ‘To’, el ‘From’ , ‘Call-ID’, etc… la lógica específica de la aplicación puede cambiar incluso el método de la petición SIP e incluso también puede cambiar SDP. El B2BUA puede generar incluso, de manera asíncrona, una petición SIP en uno de los tramos de llamada sin haber recibido ningún estímulo por el otro tramo de llamada o crear múltiples tramos de llamada, como un controlador de llamadas de terceros (3PCC). Debido a que un SIP B2BUA es sólo una colección de Agentes de Usuario SIP, estos deben entender todos los métodos, extensiones, etc, que en circunstancias normales sólo dos puntos finales tendrían que entender. La lógica usada por un B2BUA también determinará cómo se asignan las solicitudes y respuestas. Triggering Initial Filter Criteria (IFC) El “Criterio de Filtro” ó Filter Criteria es uno de los conceptos más importantes en relación a la información de usuario almacenada en la red pues determina los servicios que serán proporcionados a cada usuario. Contienen una recopilación de información relacionada con el usuario que ayuda al S-CSCF a decidir cuándo hacer participar (por ejemplo, reenviar la solicitud SIP) un determinado servidor de aplicaciones para proporcionar el servicio. Recordemos que el S-CSCF descarga los IFC cuando este se comunica con el HSS durante el proceso de registro de usuario. Los IFC son evaluados cuando se reciben peticiones iniciales SIP que crean un diálogo o bien ante peticiones independientes (es decir, aquellos que no son peticiones posteriores dentro de un diálogo SIP). Por ejemplo, el S-CSCF evalúa IFCs cuando recibe peticiones del tipo SUBSCRIBE, INVITE, OPTIONS, sin embargo no evaluará los IFCs en el caso de recibir mensajes del tipo ACK, NOTIFY, UPDATE o BYE, ya que estos siempre se envían como parte de un diálogo SIP existente. El HSS almacena todos los datos relacionados con un usuario en una estructura de da tos denominada el perfil de usuario. La siguiente figura muestra una estructura simplificada de alto nivel del perfil de usuario. El perfil de usuario contiene la Identidad de Usuario Privada (IMPI) a la que el perfil de usuario es aplicable y uno o más perfiles de servicio. Cada perfil de servicio contiene una o más Identidades de Usuario Públicas (IMPUs) para las cuales, el perfil de servicio tiene asociados ninguno o varios IFCs. Cuando el usuario se registra con el S-CSCF, este contacta con el HSS y descarga el perfil del usuario que incluye los IFCs que tenga asociados el mismo. Por tanto, los IFCs están disponibles en el S-CSCF desde el momento en que el usuario se registra. Los IFCs determinan los servicios que son aplicables al conjunto de Identidades Públicas que están incluidas en el Perfil de Usuario descargado. El primer campo de la estructura de los IFCs es la prioridad. El campo de prioridad determina el orden en el que se evaluarán estos en comparación con los restantes que forman parte del mismo perfil de servicio. El S-CSCF escoge el primer IFC que tiene una mayor prioridad, denotada por un valor más bajo (es decir, la prioridad 1 es la prioridad más alta, después continúa con los de la siguiente prioridad, por ejemplo, 2, 3, etc…). El campo de prioridad de los IFCs es un número único que lo diferencia del resto que pertenecen a un mismo Perfil de Servicio. Sin embargo, estos números no necesariamente necesitan ser consecutivos. Por ejemplo, la prioridad más alta de la primera serie de IFCs que el S-CSCF evalúa podría ser prioridad 100. El segundo podría ser prioridad 200 y así sucesivamente. Esto deja espacio para acomodar nuevos servicios entre ellos. Después de que el campo Prioridad, puede haber cero o un Trigger Points que son expresiones que necesitan ser evaluadas para determinar si una petición SIP ha de ser enviada o no a un AS. Un Trigger Point a su vez está formado por un conjunto de filtros individuales denominados Service Point Triggers. En este ejemplo, un Service Point Trigger es ‘Method = INVITE’ y otro ‘Request-URI=sip:user@example.com’. El Service Point Trigger nos permite acceder a diferente información almacenada en la petición SIP: *El valor del campo Request-URI. *El método SIP utilizado (INVITE, OPTIONS….). *La presencia o ausencia de determinadas cabeceras SIP. *El tipo de sesión (Session Case), es decir, si la petición SIP se originó por el usuario, si es dirigida al usuario, si va dirigida a un usuario no registrado, etc…; esto permitirá al S-CSCF filtrar en función de la etapa de la llamada: si se han de ejecutar triggers originantes o terminantes. *El SDP de la sesión. Si no hay Service Trigger Point, cualquier petición SIP se envía incondicionalmente al AS. Después de los Trigger Points, que contienen uno o más Service Trigger Points, los IFCs contienen la SIP URI del AS. Esta es la dirección del AS que recibirá la petición SIP si se cumplen las condiciones descritas en los Trigger Points. Existe un campo de control por defecto (Default Handling) que indica la acción a realizar en caso de que el S-CSCF no pueda contactar, por el motivo que sea, con el AS indicado. Estas acciones pasan bien por continuar con la sesión o abortarla. El campo de Información de Servicio (Service Information) contiene algunos datos que el AS puede necesitar para procesar la solicitud. El uso de este campo se limita a las peticiones de registro principalmente. Por último, el perfil de usuario se codifica mediante XML. Los IFCs son transportados desde el HSS al S-CSCF mediante mensajes diameter. Evaluaciçon de Triggers Como hemos dicho, el S-CSCF evalúa los IFCs cuando recibe una petición del tipo SUBSCRIBE, INVITE (el caso que vamos a ver más a fondo) u OPTIONS. Cuando se evalúa una serie de IFCs, y suponiendo que el resto de los campos en el Service Point Trigger son correctos, entonces el campo ‘Session Case’ se utilizará para determinar si se debe disparar al AS basándose en esos IFCs o no. Si estamos en el lado de origen de la llamada, entonces el Trigger se ejecuta si el sesión case es originante y, por el contrario, si estamos en el lado de terminación de la llamada, el Trigger se ejecuta si el sesión case es terminante. Al principio del proceso de evaluación del IFC, el S-CSCF construye una lista ordenada (por orden de prioridad) de los IFCs aplicables en función de la información de llamada. Estos IFCs serán disparados en orden hacia el AS correspondiente usando la información de sesión contenida en cada IFC. Para las llamadas originantes, el S-CSCF inicia la evaluación de IFCs cuando recibe el INVITE del P-CSCF, creando un nuevo diálogo. La IMPU utilizada para obtener la lista de IFCs será la cabecera P-Asserted-Identity. Es necesario que esta IMPU esté ya registrada en IMS antes de que se lleve a cabo la evaluación del IFC. Para las llamadas terminantes, el S-CSCF inicia la evaluación de IFCs cuando recibe el INVITE del I-CSCF, creando un nuevo diálogo. También se inicia la evaluación cuando se recibe un INVITE del AS con una nueva Request-URI. En este caso no es necesario que la IMPU esté registrada en IMS al inicio de la evaluación. Existe una clara diferencia en la forma en que el S-CSCF maneja los IFCs originantes y terminantes. Cuando el S-CSCF se da cuenta de que un AS ha cambiado el Request-URI, en el caso de IFCs terminantes, para su ejecución y enruta la petición en base al nuevo valor de la R-URI. En el caso de IFCs originantes el S-CSCF continuará evaluando los IFCs hasta que todos hayan sido evaluados. ''El Identificador Original de Diálogo (ODI)'' Cuando un UA ‘A’ llama a un UA ‘B’, el INVITE se envía desde el P-CSCF al S-CSCF; el S-CSCF se encarga de añadir un identificador específico de dicha implementación a su propia entrada en la cabecera Route. Este identificador se conoce como Identificador Original de Diálogo (Original Dialog Identifier). Este identificador se pone a un valor que permite identificar el diálogo creado con ese INVITE. El mismo tratamiento se aplica para el caso terminante donde el S-CSCF recibe mensajes, normalmente del I-CSCF. ''¿Cuál es el propósito de este ODI?' Como ya se ha mencionado, el AS se comporta como un Back-to-Back User Agent (B2BUA) por lo que termina las peticiones SIP de manera local. Esto provocaría entonces el envío de un nuevo INVITE con un nuevo Call-ID hacia el S-CSCF. Como el AS usaría el URI incluido en la cabecera Route para enrutar hacia el siguiente salto, el S-CSCF recuperaría el identificador de diálogo. Por consiguiente, el S-CSCF reconoce que el nuevo Call-ID está, de hecho, relacionado con la solicitud INVITE anterior. El S-CSCF entonces volvería al punto donde se detuvo después de enviar el primer INVITE al AS (es decir, evaluaría el siguiente IFC). Para ilustrar este comportamiento vamos a escenificar un ejemplo de cómo el S-CSCF construye la lista ordenada de triggers después de evaluar la lista completa de IFCs asociada a una IMPU determinada, para los casos originante y terminante. Supongamos que la IMPU de un usuario cualquiera está ya registrada. Esa IMPU la denotaremos como sip: user1@home1.com. Esto quiere decir que el S-CSCF ya tiene descargada la lista completa de IFCs asociados a dicha IMPU. La información contenida en dicha lista puede ser algo parecido a lo mostrado en la siguiente tabla: En primer lugar, consideremos el caso en que la IMPU sip: user1@home1.com hace una llamada a la IMPU sip: user2@home2.com. Haremos uso de dos usuarios sip para simplificar el enrutamiento final a la red terminante. En caso de que el usuario llamado no fuese sip, sino, por ejemplo un usuario PSTN o un móvil, la red terminante no sería IMS y el I-CSCF no sería contactado. En su lugar se ejecutará un breakout hacía CS/PSTN (Circuit Switch). Estas decisiones de enrutamiento se realizan utilizando procedimientos de DNS/ENUM 24 sobre los que no haremos hincapié por quedar fuera del scope de este proyecto. Como se ha dicho, el S-CSCF construirá una lista ordenada con los IFCs que aplican basándose en las condiciones mencionadas: sesión case, método, etc… En nuestro caso, el sesión case será Originating y el método INVITE. Según estas condiciones la lista ordenada de IFCs a procesar es: IFC3 ---> IFC2 ---> IFC15 En el caso originante esta lista se ejecuta sin interrupciones estando la información de servicio asociada a cada IFC contenida en el INVITE como parte del parámetro ‘’call’’ de la cabecera Route. Por lo tanto, en este caso en particular, se dispararán 3 triggers desde el S-CSCF al AS: #select-scp #orig-serv #orig-vpn Consideremos ahora el caso en el que la IMPU sip: user2@home2.com llama a la IMPU sip: user1@home1.com. Como se ha dicho, el S-CSCF de la red terminante construirá una lista ordenada de los IFCs aplicables basado en las condiciones mencionadas anteriormente: sesión case, método, etc… En nuestro caso, el sesión case será Terminating y el método INVITE. Dadas estas condiciones, la lista ordenada de IFCs a procesar es: IFC8 ---> IFC22 En el caso terminante la ejecución de esta lista puede ser interrumpida (normalmente cuando el AS envía una R-URI diferente a la recibida), estando la información de servicio asociada a cada IFC contenida en el INVITE como parte del parámetro ‘’call’’ de la cabecera Route. Por lo tanto, en este caso en particular, se dispararán 2 triggers desde el S-CSCF al AS: #term-vpn #term-serv-last Asumamos para este ejemplo que el AS no cambia la R-URI durante estas interacciones terminantes, y por lo tanto la ejecución de la lista original de IFCs no es interrumpida.